C#: Handle some BMN garbage types.#18894
Merged
michaelnebel merged 9 commits intogithub:mainfrom Mar 7, 2025
Merged
Conversation
820737e to
c4033f2
Compare
michaelnebel
commented
Feb 28, 2025
| bool duplicationGuard, deferred; | ||
|
|
||
| if (ExtractionContext.Mode is ExtractorMode.Standalone) | ||
| if (ExtractionContext.IsStandalone) |
Contributor
Author
There was a problem hiding this comment.
Note, that this is not semantically equivalent! But the original code looks like a mistake.
3c5e02f to
f061860
Compare
…he only flag set is Standalone.
65225b3 to
6f80c56
Compare
6f80c56 to
5c931fa
Compare
tamasvajk
reviewed
Mar 5, 2025
| // (1) public class { ... } is a broken type as it doesn't have a name. | ||
| // (2) public class var { ... } is an allowed type, but it overrides the `var` keyword for all uses. | ||
| // It is probably a better heuristic to treat it as a broken type. | ||
| return string.IsNullOrEmpty(symbol.Name) || symbol.Name == "var"; |
Contributor
There was a problem hiding this comment.
Are there other names that should be treated the same way? For example dynamic, nint, nuint?
Contributor
Author
There was a problem hiding this comment.
Yes, we can definitely extend the list with more "reserved" names.
| public ExtractorMode Mode { get; } | ||
| public string OutputPath { get; } | ||
| public IEnumerable<CompilationInfo> CompilationInfos { get; } | ||
| public bool IsStandalone => Mode.HasFlag(ExtractorMode.Standalone); |
Contributor
There was a problem hiding this comment.
Do we still need a public Mode property? Can it be made private?
Contributor
Author
There was a problem hiding this comment.
No, it the value itself is written to trap outside this file (it is written to file_extraction_mode).
tamasvajk
approved these changes
Mar 6, 2025
Contributor
Author
|
Will run DCA one more time. |
Contributor
Author
|
No further comments on the latest DCA run compared to the previous ones. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In this PR we categorize some types as unknown types even though they are not considered error types in Roslyn in BMN. An example of this is that in the
roslynproject a type namedvaris introduced. Since all files are crammed into a single compilation all implicitly typed declarations are considered to have typevar- which is definitely wrong. Instead we should/can consider the type to be unknown (a better solution is of course to get the type right).Analysis of DCA results:
nightly/nightly: Onlyroslynandmonoappears to be affected (these are the projects that has different tuple counts on some of the quality queries). This is not surprising as it are those projects that have broken types defined (for instance a type namedvarand a type without a name). There doesn't appear to be any performance degredations. Tens of thousands of false positives for thecs/call-to-object-tostringhave been removed. Some new false positives have been introduced for some of the other quality queries - most prominently iscs/constant-condition. Improving this again will require further investigation (I think this is due to improper handling of unknown types inisMatchingConstant- will make a follow up PR for that). All this boils down to incorrect typing of expressions and variables. DCA also shows an explosion of expressions inroslynthat doesn't have a type. This is expected as most expressions inroslynwere assigned an incorrect type (either the typevaror the type without a name).nightly/security-extended: No changes in results or performance.